Date: Wed, 26 Jan 94 04:30:05 PST From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: Bulk Subject: TCP-Group Digest V94 #22 To: tcp-group-digest TCP-Group Digest Wed, 26 Jan 94 Volume 94 : Issue 22 Today's Topics: Ethernet ID's Ethernet protocol ID (3 msgs) GPIB and packet (2 msgs) help understanding the division point of protocol vs app JNOS, TNOS, and other DOS'isms (4 msgs) JNOS problems... limiting socket connections TCP MSS and TCP WIN settings (5 msgs) Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Wed, 26 Jan 94 09:30:54 GMT From: Alan Cox Subject: Ethernet ID's To: tcp-group@ucsd.edu One is posted to usenet occasionally. There are two problems howver. Firstly I can't find my old copy or remember the group, secondly some of it is guesswork because Xerox don't reveal who owns what ID or what for. Alan ------------------------------ Date: Tue, 25 Jan 1994 13:04:42 -0600 (CST) From: drk@fed-ins.ca (Dan Keizer) Subject: Ethernet protocol ID To: tcp-group@ucsd.edu Does anyone know where I can find a concise (or as consise as possible) listing of known ethernet protocol id's?? I know in the ethernetdump routing in NOS it identifies 3 of them and then just displays the protocols' number otherwise. I checked the RFC's but nothing stood out as describing the #'s, even though I did look through quite a few. (what a maze) Dan. ------------------------------------------------------------------------ Dan Keizer, VE4DRK Federated Insurance Company of Canada drk@fed-ins.ca 717 Portage Ave, Winnipeg, MB R3C 3C9 Opinions are mine and that's that. TEL:(204) 786-6431 FAX:(204) 786-5707 ------------------------------ Date: Tue, 25 Jan 1994 21:11:13 +0000 (GMT) From: jerry@tr2.com Subject: Ethernet protocol ID To: drk@fed-ins.ca (Dan Keizer) > > Does anyone know where I can find a concise (or as consise as possible) > listing of known ethernet protocol id's?? I know in the ethernetdump > routing in NOS it identifies 3 of them and then just displays the protocols' > number otherwise. I checked the RFC's but nothing stood out as describing > the #'s, even though I did look through quite a few. (what a maze) **** FTP Software has this fantastic poster that splits ethernet packets up into protocol layers and lists all or many of the fields in each layer. They usually give it out at trade shows, and if you called them and asked nicely, they just might send you one. I don't think you'll find enet packet types in an RFC; ethernet is not really an IP protocol. - Jerry, KF6VB p.s. You think the RFCs are a morass? You should try token ring some time. Now, THAT's a morass! *************************************************************** * Jerry Kaidor jerry@tr2.com, jkaidor@synoptics.com * * jerry@KF6VB.ampr.org * *************************************************************** ------------------------------ Date: Wed, 26 Jan 94 01:44:00 -0000 From: mikebw@bilow.uu.ids.net (Mike Bilow) Subject: Ethernet protocol ID To: tcp-group@ucsd.edu Cc: drk@fed-ins.ca In a msg on , Dan Keizer writes: DK> Does anyone know where I can find a concise (or as consise as DK> possible) listing of known ethernet protocol id's?? I know DK> in the ethernetdump routing in NOS it identifies 3 of them DK> and then just displays the protocols' number otherwise. I DK> checked the RFC's but nothing stood out as describing the DK> #'s, even though I did look through quite a few. (what a DK> maze) There is a pretty good listing in the ETHLD???.ZIP package available from ub4b.buug.be in /pub/ub4b/network/msdos. This is a public domain Ethernet protocol analyzer. For those unable to access it by Internet FTP, I have it available for dial-up download at the N1BEE BBS, +1 401 944 8498, as ETHLD103.ZIP. The file is about 140 KB. -- Mike ------------------------------ Date: Tue, 25 Jan 94 13:03:33 EST From: crompton@NADC.NADC.NAVY.MIL (D. Crompton) Subject: GPIB and packet To: TCP-Group@UCSD.EDU, jas@hplb.hpl.hp.com FYI - The Circuit Cellar BBS has a parallel to GPIB adapter info and SW GPIBLPT.ZIP Doug ------------------------------ Date: Wed, 26 Jan 1994 09:28:19 EET-2EEST From: "Markus Lamminmaki OH6LSA" Subject: GPIB and packet To: crompton@NADC.NADC.NAVY.MIL (D. Crompton) >FYI - > >The Circuit Cellar BBS has a parallel to GPIB adapter info and SW > >GPIBLPT.ZIP I tried to look for it with archie but could not find any references. Could you put it somewhere where I could ftp this file from. --- Vasa Polytechnic Email: markus@technis.vtyh.fi PB 6, SF-65201, FINLAND postmaster@vtyh.fi Fax: +358-61-3230 610 Work:+358-61-3230 661 Home: +358-61-3171 466 Looks great on the outside, but Intel inside. ------------------------------ Date: Tue, 25 Jan 1994 22:40:11 -0800 From: Phil Karn Subject: help understanding the division point of protocol vs app To: mikebw@bilow.uu.ids.net Ah yes, the layering wars...takes me way back... A few random tidbits: Postel and Cohen published a paper a while back that shows that if the ISO 7-layer model is correct, then n = n+1. (This is known as a disproof by contradiction). The problem, btw, comes when you stack up things in an ad-hoc fashion, as so often happens in the real world both because it's often necessary and because the Internet protocols make it so easy to do. For example, it would be entirely possible to encode IP inside email messages and build a (slow) "super internet" out of it. Then which layer do your mail-encoded IP headers belong to? Okay, so this might be crazy. But what about the idea of encoding SLIP or PPP packets as lines of ASCII characters and sending them over a Telnet connection to a server out on the net that unwraps them and puts them back out on the net? (I've been threatening to do exactly this in NOS for some time to give people a way to get logical IP connectivity to the Internet through public-access UNIX sites on the Internet that either don't provide SLIP/PPP service, or charge ridiculous prices for it.) What matters is the order in which you stack the protocols, not what "ISO layer name/number" you should assign to each one. Perhaps the best philosphy I've heard is "layering makes a good servant, but a bad master". Who said this? Dave Clark? Phil ------------------------------ Date: Mon, 24 Jan 94 22:50:07 PST From: algedi!gateway (gateway) Subject: JNOS, TNOS, and other DOS'isms To: tcp-group@ucsd.edu In your message of Fri, 21 Jan 1994 20:56:00 GMT, you write: +--------------- |people were not arguing over it. No one knows what the future is going to look |like, but I personally hope it looks a lot more like Unix or OS/2 than Windows. | My own view is that it is up to the people who write the source code. +------------->8 Only in part; but as always, the final decision is up to the people who *use* the code. There are several choices for Unix "NOS" (in quotes because I include kernel-based solutions that don't involve dedticated NOS executables) already; OS/2 NOS development seems to be lagging, and I'm not sure what there is (native) for MS-Windows, if anything; but, should those environments have NOS versions available, which one will be "the" future NOS environment will depend on how many people choose which environments. (Nor is this specific to NOS. The same considerations apply to the choice of environment for any other application, whether it be amateur radio networking or databases.) What the developers do is enable that decision to be made; they don't make the decision for you. ++Brandon -- Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.org "MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development." ---dmeggins@aix1.uottawa.ca ------------------------------ Date: Mon, 24 Jan 94 23:50:04 PST From: algedi!gateway (gateway) Subject: JNOS, TNOS, and other DOS'isms To: tcp-group@ucsd.edu >It would be fairly easy to generate a special header file for older Borland >compilers that would implement some extremely simple text translations, such >as defining the newer prefaces (like "_dos_") so that they were stripped by >translating them to empty text strings. I took an easier route. I got rid of the DOS on top of DOS code! I don't see any reason for DIR RENAME and COPY inside NOS (as well as a lot of other fluff) and I just deleted all that bo-jive. Which brings me to my political comment of the month. One thing I *really* don't like about JNOS and TNOS is their attempt at loading all these MS-DOS features into the code. Get rid of that CRAP and get back on track. The other thing is the BBS code. I'd throw away all that mailbox CRAP, it's obsolete. Why not expand on the NNTP and make a nice news feed. Your local community would probably appreciate the breath of fresh air from the obsolete BBS interface, addressing, and forwarding methods. By the way I use DesqView and a simple ALT-ALT tap gets me a nice window that does all that CRAP that is flowing into NOS. Windows could do the same, but it needs a lot more memory I suspect. Those were very useful comments though, about the BC limitations and changes Mike, thanks. --- Steve N5OWK@W1AW.#LEFT.#RIGHT.#LEFT.#UP.#DOWN.#AROUND.CT.USA.NA.EARTH.ZF101 "My views are official and represent the governments feeling on the subject" ------------------------------ Date: Tue, 25 Jan 94 01:50:04 PST From: algedi!gateway (gateway) Subject: JNOS, TNOS, and other DOS'isms To: ssampson@sabea-oc.af.mil, tcp-group@ucsd.edu > I took an easier route. I got rid of the DOS on top of DOS code! I don't see > any reason for DIR RENAME and COPY inside NOS (as well as a lot of other fluff) > and I just deleted all that bo-jive. Which brings me to my political comment The reason for having those in the code is so you don't have to shell out (and worry you still have enough core left) when you want to do that dir, more, delete, or rename). If you don't need these, the ifdef the commands out (that's what config.h is for). > ... The other thing is the BBS code. I'd throw away > all that mailbox CRAP, it's obsolete. Why not expand on the NNTP and make a > nice news feed. Your local community would probably appreciate the breath of > fresh air from the obsolete BBS interface, addressing, and forwarding methods. Those of us on the local frequency would probably agree. Why don't you write a version for us that has a decent nntp and full smtp support (for those of us who don't have >1M of memory and can't multitask :). Don't forget to include a sysop shell for remote node support (yes, we use sysop here to remotely control stations, such as the router). Ohh yea... converse is one of the most popular IP modes around here, although we could use a multicast protocol :). [I guess this called "put you code where your mouth is :) ] [Not to say I am not working on any of this, just that I have to complete some other projects before I can work on my release of nos ... ] milton -- Milton Miller KB5TKF miltonm@austin.ibm.com I never speak for IBM. ------------------------------ Date: Tue, 25 Jan 1994 15:47:50 -0600 (CST) From: ssampson@sabea-oc.af.mil (Steve Sampson) Subject: JNOS, TNOS, and other DOS'isms To: algedi!gateway (gateway) > > > > I took an easier route. I got rid of the DOS on top of DOS code! I don't see > > any reason for DIR RENAME and COPY inside NOS (as well as a lot of other fluff) > > and I just deleted all that bo-jive. Which brings me to my political comment > > The reason for having those in the code is so you don't have to shell out > (and worry you still have enough core left) when you want to do that > dir, more, delete, or rename). If you don't need these, the ifdef the > commands out (that's what config.h is for). > > > ... The other thing is the BBS code. I'd throw away > > all that mailbox CRAP, it's obsolete. Why not expand on the NNTP and make a > > nice news feed. Your local community would probably appreciate the breath of > > fresh air from the obsolete BBS interface, addressing, and forwarding methods. > > Those of us on the local frequency would probably agree. Why don't you > write a version for us that has a decent nntp and full smtp support > (for those of us who don't have >1M of memory and can't multitask :). > Don't forget to include a sysop shell for remote node support (yes, we > use sysop here to remotely control stations, such as the router). > Ohh yea... converse is one of the most popular IP modes around here, > although we could use a multicast protocol :). > > [I guess this called "put you code where your mouth is :) ] > > [Not to say I am not working on any of this, just that I have to complete > some other projects before I can work on my release of nos ... ] > > milton > -- > Milton Miller KB5TKF miltonm@austin.ibm.com > I never speak for IBM. > > > Why am I getting mail from this machine?? It's echoing everything with a two day delay or more... -- Steve ------------------------------ Date: Mon, 24 Jan 1994 22:54 +0200 From: "Miroslav Skoric, SysOp in YU7B, Novi Sad" Subject: JNOS problems... To: fon!tcp-group@ucsd.edu Hello there... I've installed JNOSv1.10x9 and have configured it only as "normal" packet ax.25 station. Unfortunately, I really don't know how to make it full tcp/ip packet/internet bbs (or) gateway, which was the main reason for supplying such software. I've been running ax.25 packet bbs YU7B.SRB.YUG.EU with telephone modem access possibility and I have user access to the local Internet/VAX system via phone modem. I want to run this JNOS as full packet-internet bbs. I've made dialer, forward.bbs and the other files, but I am not able to connect anyone via phone modem now, especialy not automaticaly as, for example FBB software does. If somebody could help me to establish the FIRST tcpip bbs in YU* land, don't hesitate to contact me, either via Internet or packet radio. If using Internet pse don't press REPLY now, but instead type the whole address: skoric%unsim%etfbg%fon.uucp@moumee.calstatela.edu or via packet: YT7MPB@YU7B.SRB.YUG.EU Best wishes and 73 from Misko, YT7MPB ------------------------------ Date: Tue, 25 Jan 94 11:04:18 PST From: Glenn Engel Subject: limiting socket connections To: tcp-group@ucsd.edu I've seen a number of references to people having problems with sockets hanging around "forever". The following patch is one I've used to help with this problem. When a new connection is initiated, a check is made to see if the current number of connections is greater than the tcpMaxConn limit. If the limit is exceeded, the connection which has been idle for the longest period of time will be closed. By setting the tcpMaxConn value large enough to cover "active" connections, this effectively causes old connections to die a graceful death. No copyright implied or assumed for this software. Use it however you wish. -- Glenn *** /usr/tmp/fdif1AAAa12357 Tue Jan 25 13:56:25 1994 --- tcpin.c Mon Jan 24 12:01:41 1994 *************** *** 23,28 **** --- 23,59 ---- uint16 *length); static int in_window(struct tcb *tcb,int32 seq); + /**********************************************************************/ + /* This function attempts to limit the number of tcp connections. It */ + /* walks thru the list of tcbs and counts all connections which are */ + /* not in the CLOSED or LISTEN state. If this count is greater than */ + /* the limit then the tcb which was used last is removed. Because */ + /* lookup_tcb puts found items at the head, we know that the tail of */ + /* the list is the tcb which has the greatest time since last used. */ + /**********************************************************************/ + void checkNumTcbLimit(void) + { + struct tcb *tcb; + struct tcb *tcblast; + int numTcb = 0; + + for(tcb=Tcbs;tcb != NULLTCB;tcb = tcb->next) + { + if ((tcb->state > TCP_LISTEN) && (tcb->state < TCP_FINWAIT1)) + { + numTcb++; + tcblast = tcb; + } + } + + if (numTcb >= tcpMaxConn) + { + /* drop the oldest tcb */ + close_tcp(tcblast); + } + } + + /* This function is called from IP with the IP header in machine byte order, * along with a mbuf chain pointing to the TCP header. */ *************** *** 133,138 **** --- 164,171 ---- return; } if(seg.flags.syn){ + /* check for too many tcbs */ + checkNumTcbLimit(); /* (Security check is bypassed) */ /* page 66 */ proc_syn(tcb,ip->tos,&seg); ------------------------------ Date: Mon, 24 Jan 1994 23:11:02 -0800 From: Phil Karn Subject: TCP MSS and TCP WIN settings To: CHRISC@Central.nmmc.mn.org >I don't see how you could tell. The determination of how a packet is >routed is under the auspices of IP not TCP. It is quite conceivable, >even on a radio circuit, that a packet (or rather stream of >characters) which is queued, but not acknowledged, could be resent by >a completely different path on each attempt at transmission. You are quite correct; the trick of asking the IP layer for the MTU of the interface that is currently used to reach the remote site *is* a layering violation, and as you say the interface can change anyway. But it does so only rarely in practice, so it's a useful violation. These issues are actually longstanding problems with TCP/IP. The first one, determining the largest MSS that will avoid fragmentation, now has a proper solution - MTU path discovery. The sender sets the "DF" (don't fragment) flag in every IP header. If the packet hits a gateway with an interface that requires fragmentation, the packet is bounced with an ICMP "Unreachable - fragmentation required and DF set" message. If the ICMP message includes the interface MTU so the sender can know how much smaller to make the packet -- unless, of course, there's another router down the line with an even smaller MTU. The trick is that the ICMP message didn't include the interface MTU until the MTU path discovery feature was adopted. If the "bottleneck" router doesn't support it, then the sender has to guess at a packet size that will fit - simply halving the packet size until it gets through will probably work. I put in the ICMP MTU reporting feature some time ago, but I haven't done the needed work in TCP to actually invoke it yet. I figured that I should let the ICMP update percolate around first (that is, if anybody's tracking my code anymore). Perhaps it's time to finish the job. The other problem, that of controlling the TCP window size, is much more problematical. What you really want to control is *not* the window size that the receiver advertises - this simply indicates how much memory it has available for buffering - but the effective, or "congestion" window that the sender uses. Van Jacobsen made a tremendous advance in this area some years back by introducing the congestion window concept and the "slow start" and "congestion recovery" algorithms that adjust it. My TCP was one of the first (after Van's) to implement it, because amateur packet radio channels are as congested as any that support TCP. But Van didn't solve the whole problem, because the only way to keep the congestion window from eventually increasing all the way to the window advertised by the receiver is to drop a packet, and this is wasteful. And it's possible for several TCPs all running slowstart to get locked into a relaxation cycle: they all increase their congestion windows together until the network starts dropping their packets, then they back off again and start the process all over. One elegant solution is the "DEC Bit" scheme proposed by DEC for ISO CLNP. When a router experiences congestion on a link, it sets a "congestion experienced" bit in the header. The receiver echoes this bit back to the sender in its transport ACK header, and the sender modulates his congestion window appropriately. The idea is to keep the bottleneck link along the path just saturated, without piling up a long queue behind it. I've wanted to put this into TCP/IP for some time (can't stand the notion of there being a useful feature in ISO that's not in TCP/IP!) but it requires the cooperation of a lot of vendors to make this happen. So I've long been interested in backward-compatible schemes to accomplish the same thing. I haven't found any that really work, but that's probably because I don't know enough control theory. So just to do something to keep queues reasonable, I stuck in a "qlimit" feature. Whenever an interface transmit queue exceeds the queue limit, the routing code picks a packet at random from the queue and sends a source quench to its sender (without dropping the packet). This could be called a "random quench" policy. The TCP that gets the quench will shrink its congestion window to 1 packet, just as if it had encountered a timeout. The congestion window will still oscillate, but it definitely does keep the queues shorter. Van Jacobsen and Sally Floyd did recently publish a paper in ACM/IEEE Networks magazine on some much more clever congestion avoidance algorithms for gateways. I have a copy and will implement it when I get a chance. In the meantime, if somebody can come up with a simple, reliable and stable algorithm for setting the TCP congestion window to the right value just by observing changes in round trip delays and bandwidths, you could make yourself famous. Phil ------------------------------ Date: Tue, 25 Jan 1994 09:20:13 -0500 From: goldstein@carafe.tay2.dec.com Subject: TCP MSS and TCP WIN settings To: tcp-group@ucsd.edu Phil, Several years ago, Raj Jain and K.K Ramakrishnan (I think it was the two of them as a team) published a paper describing a congestion avoidance scheme based on round-trip delay observation. I haven't looked at it for a while but my recollection is that they weren't impressed by the results, so they didn't pursue it farther. (Note to net_readers: Jain actually invented the scheme that Van Jacobsen is widely credited for; it was done for DECnet Phase IV in 1984 and Jacobsen acknowledges it in his own paper. Jacobsen made a minor improvement of his own.) Folks at Digital have been trying for years to get the IETF to put a DECbit into IP, but it keeps running into two political problems. One, it was invented elsewhere, and is tainted by the OSI label (since they took Digital's suggestion). Two, it is hard to phase in: If you put DECbit congestion avoidance into your TCP and I don't put it in mine, you'll slow down (nice fella!) and I won't, and I'll be taking advantage of the bandwidth you freed up. It's a "nice guys finish last" scenario. WIth all of the J-random implementations of TCP floating around, this might be a real issue for a while, though there are of course workarounds. ("MANDATORY" worked for V.J.) Frame Relay (T1.618/Q.922) has a FECN bit which is there explicitly to support this "DECbit" concept. If we can't get it into IP, maybe it should go into IPNG, whatever that turns out to be. fred k1io ------------------------------ Date: Tue, 25 Jan 94 14:56:00 CST From: andyw@aspen.cray.com (Andy Warner) Subject: TCP MSS and TCP WIN settings To: tcp-group@ucsd.edu (TCP Group) Phil wrote: > [...] > I put in the ICMP MTU reporting feature some time ago, but I haven't > done the needed work in TCP to actually invoke it yet. I figured that > I should let the ICMP update percolate around first (that is, if > anybody's tracking my code anymore). Perhaps it's time to finish the > job. > [...] I can vouch for the MTU reporting abilities of most recent versions of NOS, a while back I tried to hack MTU discovery into SunOS 4.1.2 - but for some reason (on the sun) it didn't seem to work too well. Locally, we came up with a far more draconian fix (MSS & window snooping - NOS actually alters the packets as they pass through). Before I get long, angry flames from the four corners of the world, this was to fix the specific problems of *nix boxes on local ethernets which had the misfortune of being linked by AX.25. It has been working well for over a year now. I'm putting a SunOS 4.1.3 machine up soon, maybe I'll revisit path MTU discovery.... -- andyw. N0REN/G1XRL andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835 ------------------------------ Date: Tue, 25 Jan 1994 13:13:50 -0800 From: Phil Karn Subject: TCP MSS and TCP WIN settings To: goldstein@carafe.enet.dec.com Fred, Now that you mention it, I do remember that Raj invented what Van called "slow start". I *think* Van said he reinvented it independently. In any event, Raj picked the wrong protocol stack to implement it in, so Van gets all the credit. :-) I really don't think NIH explains why the DECbit scheme didn't get into IP. Nor is there a "nice guys finish last" problem. If anything, there should have been one with slow start, but it got deployed pretty quickly anyway. I think there are three problems: one, there was a widespread perception that there must exist a way to control gateway congestion without having to modify IP and every router that handles it. Two, the NSFNet backbone bandwidth has increased almost 1,000x over what it was back when TCP congestion control algorithms were such a hot topic. Despite the enormous growth of the net this has pretty much eliminated the widespread backbone congestion that used to occur back then, so there is now much less interest in this problem. Three, both TCPs in a connection have to be aware of the scheme, because the sending TCP relies on the other TCP to "reflect back" the IP congestion experienced bit in its own header. Van has contributed greatly to the first problem. I remember some really strong arguments at IETF meetings between him and Raj and KK about whether the DECbit scheme was really needed, or whether you could do everything with packet drops and throughput/delay measurements. By the time everybody sort of came to the conclusion that Raj and KK were right, the problem had sort of lost its appeal. I still think it's not too late to install the Decbit scheme in IP. There's a spare bit in the flags field (right next to the MF and DF bits) that could be used. I've had code in my own IP and TCP for some time that reflects this bit back in another spare bit in the TCP header, in preparation for eventually implementing the scheme. Again, I wanted to make sure that there would be enough compatible systems out there to make this thing work. But I haven't taken it beyond that. Maybe it's time to try it, at least experimentally, and then write up an Internet Draft. One remaining concern: how many broken hosts and gateways either refuse to pass this (currently unused) IP header bit, or worse, will break when it is set? Phil ------------------------------ Date: Wed, 26 Jan 94 09:50:28 GMT From: Alan Cox Subject: TCP MSS and TCP WIN settings To: CHRISC@Central.nmmc.mn.org, karn@qualcomm.com This of course raises the other peril of MTU discovery - packets which go off on different routes. The single MTU is all very well until one stray packet goes via a low mtu link due to congestion - now everything you send suffers. Alan ------------------------------ Date: Mon, 24 Jan 94 20:50:06 PST From: algedi!gateway (gateway) To: tcp-group@ucsd.edu help -- Eric T. Budinger Dan's Domain 201-586-1223 budinger@ds.gen.nj.us Ham Central SysOp ericbud@ritz.mordor.com 1-201-398-4619 (voice) n2koj@w2xo.pa.usa.na 1-201-205-2134 (digital) ------------------------------ End of TCP-Group Digest V94 #22 ******************************